This invention relates generally to the identification of screen objects by an analysis of their characteristics in a computer graphical user interface and specifically to the identification of screen objects for purposes of implementing a help system in a computer providing a windows environment.
Today's computer systems typically provide a graphical user interface (GUI) that allows a user to operate the computer system by using a pointing device such as a mouse to control a pointer on the screen to select and activate objects corresponding to the images. The images, or objects, on the screen can be controls such as a button, slider or scroll bar; an icon corresponding to a program or file; a tool, utility or other mechanism that facilitates the user's operation of the computer system such as a window, etc. Thus, in a typical GUI, each object capable of manipulation has an associated object image that is displayed on the screen and which the user can select and activate by means of the mouse and pointer.
The selection and activation of the various objects allows the user to accomplish a variety of tasks such as operating application programs or invoking operating system commands. Most popular GUIs provide a windows environment where application programs are executed within one or more windows on the screen. Each window is a rectangular area on the screen that can be repositioned, resized, opened, closed, etc., in any a variety of well-known ways.
One popular type of windows environment is Microsoft Windows (MSW) by Microsoft Inc. The MSW environment has become quite popular as the environment of choice on many personal computer systems. For ease of discussion the invention is discussed below in relation to Microsoft Windows. However, any suitable windows environment such as the Macintosh Operating System by Apple Computers, Inc. is suitable for use with the present invention.
One feature of Microsoft Windows is that an automated help system is provided. The help system allows a user to receive information about objects on the screen or access general topics of interest in operating a given application. A user of the help system is allowed to select among topics and obtain help information on the topic (topic help). Other systems allow a user to obtain short one or two lines of help information (short help) on specific topics or objects. A convenient way to access the topic or short help is by pointing to objects with the mouse and pointer in order to obtain "context sensitive" help.
Context sensitive help is especially useful to a user who is first becoming acquainted with the operation of an application program. By using context sensitive help, the user selects a predetermined key sequence such as the key sequence CTRL-F1 when the pointer on the screen is overlapping (or "focused on") a specific object. The help system then provides informative text on the object by accessing a help text file that is associated with the application program. To the end user, the operation of the help system is easy and efficient. However, the creation of the help text and association of the help text with objects in a given application program is performed by a programmer/developer at some time prior to the user's help session. Currently, the development of help text and the association of the help text with objects is a burdensome procedure.
One severe drawback of the current help text development systems is that the help text developer must have access to a given application program's source code in order to associate help text with the various objects within the application program. This means that the help text developer must work with the application programmer in order to place associations between objects and help text. Not only does this make it very difficult to coordinate the development of help text while an application program is under development, but it makes it impossible to create specific help text for already existing applications since most applications are created by third party software developers and are shipped only as executable objects without the source code. Thus, it is impossible for a help text developer to create new and customized help text for existing applications.
FIG. 1 shows the prior art help system. In FIG. 1, application source code 10 is the starting point for associating context numbers with objects in the application program. For each specific application program there is a different associated source code from which the application program executable is derived. Certain statements within application source code 10, such as the instruction at 22 are "calls" to functions in the MSW environment. The MSW environment is shown symbolically as MSW process 16 in FIG. 1. An example of such a function call is "Win Help (...Context # ...)" shown at 22. In practice, the label "Context #" is replaced with a value, or named constant, that corresponds to a topic within help resource file 20.
Application source code 10 is compiled via compiler 12 to produce an application executable 14. Application executable 14 is executed by the processor within MSW environment 16. MSW environment 16 accepts user input signals that trigger the WinHelp call. A message about the signals is sent to Surveillance Motor 30 which invokes windows help engine 18. Windows help engine 18 accesses help resource file 20 in order to display and process help text dealing with the topic or object referred to by the context number.
A further description of prior art help text development systems can be found in "Borland C++ Tools and Utilities Guide, Version 3.1," Chapter 7, by Borland International Inc. 1992. A description of a user interface for a help text development system is also discussed in manuals on "Help Maker" by ddtec SA. For a general discussion of the Microsoft Windows Application Program Interface (API) see references such as "Programming Windows 3.1" or "Windows 3.1 Software Development Kit," by Microsoft Press.
As mentioned above, prior art help text development systems such as the one described in FIG. 1 do not allow a help text developer to work independently with the help resource file without the source code for the application for which help text is being written. This inconvenience adds to the cost and time required to make good help text systems and makes it impossible for a third party to add help text to an existing application executable. Another problem with traditional help text development systems is that they do not allow increased flexibility in providing help to the user beyond displaying text.